The .NET Framework provides a code access security model that allows administrators to modify security policy to meet their individual needs. While code access security generally increases the reliability and security of applications, improperly administering code access security policy can potentially create security weaknesses.
The .NET Framework security system is governed by a configurable set of rules called security policy. This policy allows the end user or administrator to adjust the settings that determine which resources code is allowed to access, and ultimately decide which code is allowed to run at all.
For example, suppose you are an administrator in an enterprise setting and you do not trust the software that originates from a particular company. Perhaps that company produces software that employees find entertaining, but which causes increased network traffic or causes workstations to become unstable. You can set an enterprise level security policy that restricts the access that software has to your computer resources. You can also set a policy that prevents this publisher's software from running at all.
Code that targets the common language runtime is deployed in units called assemblies. At load time, the runtime examines each assembly for evidence, which is identifying information about the assembly (such as the digital signature of the code's author and the location where the code originates). Based on the evidence, the common language runtime security manager maps the assembly to a code group based on security policy. Code groups are defined to test for specific forms of evidence and have permission sets associated with them. Assemblies that belong to a code group receive the permissions defined by the associated permission sets. For more information about evidence, code groups, and permission sets, see Security Policy Model in the .NET Framework SDK documentation documentation.
Permissions are simply objects created by an application that represent the right to access a protected resource. Permissions are configurable and a single permission object can assume several forms. The rights that a permission represent and that assemblies receive are fully configurable by the system administrator. While applications can construct and configure permission objects like any other object, only security policy can grant a permission to an application. Administrators ultimately control the permission grant. For a list of common permissions, see Code Access Permissions in the .NET Framework SDK documentation documentation.
There are four levels of security policy defined in the security model, which correspond to the different administration and hosting scenarios. The following table describes each level. The enterprise policy level is the highest level and the application domain level is the lowest.
| Policy level | Description | Corresponding configuration file |
|---|---|---|
| Enterprise policy | Defined by enterprise administrators who set policy for enterprise domains. | %CLR installDir%\Config\Enterprise.config |
| Machine policy | Defined by machine administrators who set policy for one computer. | %CLR InstallDir%\Config\Security.config |
| User policy | Defined by users who set policy for a single logon account. | %USERPROFILE%\Application data\Microsoft\CLR security config\vxx.xx\Security.config |
| Application domain policy | Defined by the runtime host (any application that hosts the common language runtime) for setting load-time policy. This level cannot be administered. | None |
Each policy level consists of a hierarchy of code groups. Administrators of each policy level can create their own code groups and associated permission sets. At load time, the code access security system examines all policy levels and the resulting permission grant is the intersection of all allowed permissions in each level. Administrators of a lower policy level cannot loosen a policy decision made on a higher level, but they can tighten policy as much as they want. The default security policy resides on the machine policy level.
The default security settings are as follows:
Note that unrestricted user and enterprise levels do not result in unrestricted permissions being granted to an assembly. Because the machine level defines several restrictions, and all three levels are considered as a whole, the resulting permission grant is not unrestricted permission.
See the following topics in the .NET Framework SDK documentation: Security Policy Management, Security Tools, Default Security Policy, Code Access Permissions, Security Policy Model.